爱奇艺本地实时Cache方案

高并发系统离不开Cache，通过采用更多的本地Cache来提升系统吞吐量和稳定性是必然的，这其中的最大难点就是解决分布式本地Cache数据的实时性和一致性问题，否则本地Cache就无法更普遍应用于频繁变更的数据上。

没有最完美的方案，只有更合适的方案。本文将详细讲解爱奇艺TV后台分布式实时本地Cache实践方案，给大家解决高并发问题提供一个参考。

01

背景

目前互联网系统大多是读多写少的系统，面对读多写少的系统，大家一定会拆分为读系统、写系统，提高系统稳定性和吞吐量，今天我们所讲的Cache主要是面向读的系统。

爱奇艺拥有大量版权内容的Metadata，在不同的业务场景都需要将这些Metadata和相应的关联数据作为基础数据返回，为了提高业务迭代速度，降低系统耦合，我们将这些基础数据的组装环节拆分为独立的服务，该服务提供包括通用和个性化逻辑的封装，所有用到基础数据的地方调用此微服务。每条数据大约几KB到十几KB不等，且数量不断增长。该服务作为基础服务对各子业务服务。

如何解决该服务对集中式Cache带来的高并发问题（高峰期支撑百万级QPS）：比如集中式Cache内网带宽损耗、Cache网络故障超时场景等问题。以下提供众多解决方案中的一个解决方案。

02

思路&方案

首先对比一下本地Cache与集中Cache的优缺点：

1.本地Cache

其优点有：

（1）热点缓存，每扩容一个实例就相当于扩容了一个热点数据库；

（2）命中率高；

（3）过期策略；

（4）业务逻辑速度快，机器损耗低；

（5）抗风险能力强。

其缺点有：

（1）一般是被动缓存，实时性差；

（2）存储量有限，配备2GB~4GB，足矣满足当前大部分场景的热点数据。

2.集中Cache

其优点有：

（1）方便实时更新Cache；

（2）缓存一致性强。

其缺点如下：

（1）集群过大，依赖过重；

（2）并发量高时，IO过重；

（3）易受应用机器到缓存机器之间的网络抖动影响；

（4）热点Key访问量过大时，容易将带宽跑满，需要多Cache集群来解决。

对比如上优缺点，大部分人都会采用本地热点Cache，本地存储4GB一般都能满足常见的业务热点数据，但是本地Cache实时性差，如何解决实时性？如下为解决方案：

3.解决方案

通过统一的消息机制来触发本地Cache的实时更新，同时提供消息过滤机制，由业务方自行处理逻辑，这样可以实现本地Cache个性化更新方案。方案如下：

4.方案说明

（1）管理后台：管理使用该本地Cache的所有应用实例及缓存策略；

（2）数据变更：数据变更源头；

（3）消息总线：消息的集散中心；

（4）业务Filter：业务方可以自行处理部分消息；

（5）监控统计：采用爱奇艺统一的日志收集系统，可以用来统计分析热点数据，为其它热点方案提供数据支持，监控采用统一监控，监控各个实例的Cache命中等指标

03

扩展

当单个集群本地Cache命中率低于可接受临界值（比如70%）时，内存受限无法扩大本地Cache存储，可拆分成轻逻辑数据分片集群，即可提高命中率。

04

效果总结

（1）有效降低了集群雪崩的风险；

（2）解决了高并发读的问题；

（3）减少热点数据的网络穿透，降低集中式Cache的负担。

参考阅读：

技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式